Subject: Proposed Update to TRS Architecture

From: [email-masked] (Matthew Finlayson)
Date: Fri, 30 Sep 94 12:43:52 BST

Ralph,

In response to your email asking for subjects to be discussed at the
APPN Architecture Reference SIG, here's the description and our proposed
solution to a problem we've discovered in the architecture.

The problem causes routes to be calculated through nodes which are no longer
in a network.  We've come across the problem in several guises during our
live testing.

Problem:
========

The example which best illustrates this problem is as follows.

Consider the following network topology:

      NNA
     /   \
    /     \
   NNB   VRN1
    |     |
    |     |
   NNC---NND

where all links between Network Nodes support CP-CP sessions.  If NNA is now
shut down (without being quiesced), or the link between NNA and NNB fails,
then the network topology (as seen by NNB, NNC and NND) is left

      NNA
     /   \
          \
   NNB   VRN1
    |     |
    |     |
   NNC---NND

with the unidirectional TG from NNB to NNA being marked as inactive, but the
unidirectional TG from NNA to NNB, and the TGs between NNA and VRN1 remaining
in the database as active.

Now, if NND wishes to establish a session to NNB it is altogether feasible
(depending on the TG and node-weights) that it will attempt to make use of the
route NND->VRN1->NNA->NNB and session activation will fail.

One solution to the problem might be to prevent routing through a
TG when its mirror TG (ie. the same TG viewed in the opposite direction) is
marked as inactive (or is not present in the network topology).
Unfortunately, this falls down on two grounds:

  - It would hamper the use of unidrectional auto-activatable links, and
    links which support predefined TG numbers.

  - It does not solve all occurrences of the problem. Eg. in the following
    network:

     NNB---VRN1
      |     |
      |     |
     NNC---NNA
      |     |
      |     |
     NND---VRN2

    If NNA is shut down, and NND again tries to establish a session to NNA
    then it may try to route NND->VRN2->NNA->VRN1->NNB, entirely across
    bidirectional TGs.

Proposed solution:
==================

Change TRS route-calculation so that any network node which is no longer
reachable by CP-CP sessions (ie. the local node cannot build a CP-CP session
route to the remote node) has infinite weight.

This means that it will become invalid to route sessions through any
node which is not within the CP-CP session mesh.

The advantages are that all the variants of the above scenarios will
cease to be problems. The disadvantages are addressed below:

(1) The overhead involved in calculating a CP-CP session route to every node
    through which routing is desired.

    Since the proposed Architectural Update 00803 (Route Selection -
    Destination Node Changes Node Type) requires that a CP-CP sessions
    route be built to any Network Node requested by a QUERY_CP_NAME, and also
    that directed searches require such a route, it is likely that
    a tree using CPSVCMG COS will be cached by most implementations.

    In this case, the overhead should not be excessive.

(2) In some circumstances a favourable route may be avoided

    In the second network given above, imagine that the situation when the
    link between NNC and NNA fails. The route NND->VRN2->NNA->VRN1->NNB
    would work if it is tried but will no longer be generated.  This could
    mean that a route of lower cost is not used, or that the only suitable
    route is not tried.

    Although this argument is true, the ethos of APPN would surely suggest
    that we can no longer trust the information about the node which is
    no longer reachable by the CP-CP session mesh. It may conceivably have
    become congested, quiesced or the node-weight may have changed. It would
    seem that the favourable route is simply inappropriate.

It is important to note that this new proposed criteria for routing should
not apply to the calculation of routes using CPSVCMG COS (because of the
danger of recursion).

==============================================================
Matthew Finlayson                   Data Connection Limited
([email-masked])                  Telephone: +44 81 366 1177
                                    Fax:       +44 81 367 8501
==============================================================